The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
One type of computer system provides the ability to authenticate, authorize, and account (AAA) for users accessing computer services in the system on a network. The AAA services provide security to ensure that legitimate users are accepted, their access is controlled with authorization parameters, and their behaviors are tracked and audited with accounting. The AAA services also attempt to ensure that unknown or illegitimate users can be blocked. AAA services may be used in network systems, where the AAA service may be a separate process or physical device such as an access control server, or may be used in computer systems, where the AAA service is a thread or programming module running as part of a computer system on one or more physical machines. To protect users from entering “weak” or guessable passwords, some AAA systems retain password rules. These rules require certain password lengths, special characters, or other requirements for user passwords, thereby ensuring that only “strong” passwords are used.
A problem with the approach is that these systems help protect against weak passwords, but do so only at the time of password creation. Therefore, if password rules change, there is no way to ensure compliance of the passwords that are already in the repository. There is no batch mechanism to apply password rules to hundreds or thousands of passwords or to change out-of-compliance passwords that already exist in the system.
AAA servers may proxy authentication to other services or servers. For example, the AAA server may proxy an Oracle™ database server and an application-licensing server each running on separate physical machines. Each of the services may have its own password policy or security policy, may have different password policies based on the role of the user (e.g. administrator, guest, etc.), and may change its password policies over time. A second problem with the approach is that the AAA system has no mechanism for enforcing different security or password policies based on which service is being accessed, role of the user, or newly defined password rules.
Therefore, there is clearly a need for techniques to ensure that mitigating action is taken when passwords in the repository are not compliant with applicable security or password policy.